The term “client” must be understood here and further below in the description as a term that designates an entity that makes direct or indirect demands upon the resources of another entity to execute a task, a client possibly taking the form of an autonomous server, a group of servers, an application (such as an internet browser) or various elements separately distributed within various communications means included in the system.
The term “service” must be understood as the expression of the implementation of one or more functions according to a determined business sequencing used to obtain an equally determined result, such a result possibly serving as input data for another service. Indeed, a service can implement other services (for example Web services). A service can be described by means of a particular language such as BPEL (Business Process Execution Language) to enable its orchestration.
BPEL is a standard based on XML (Extensible Markup Language) used to describe business processes (here below also called applications processes) implementing Web service interactions compliant with the expectations of Web 2.0, especially in terms of dynamic quality.
The BPEL can be used especially to implement complex business processes in a synchronous mode: a BPEL process will therefore call upon Web services through requests and await responses before continuing to execute its other tasks (calling other Web services). A BPEL process can also be perceived by the clients wishing to invoke it as a synchronous Web service as such.
One drawback of this synchronous implementation is related to the execution time (often lengthy) of a BPEL applications process.
Indeed, a process of this kind, which implements numerous Web services synchronously or even asynchronously, sequentially or in combination, is often lengthy in its execution and can prompt a timeout for the caller, i.e. the client who is requesting the execution of an applications business process (of the BPEL process type) formed by a consistent set of Web services.
A “timeout” can be likened to an untimely stoppage of the client when a time of response to a request has gone beyond a certain time limit. A known and common example of a timeout takes place when a user tries to access a Web page that exists and whose downloading gives rise to an excessively lengthy waiting time (because the data is too bulky) for the service originating the request for downloading. The Web server then sends a timeout. Because of the sequencing of several Web services synchronously or even asynchronously, a comprehensive BPEL applications process can prompt such a timeout for the client since this client receives any response to its request immediately or within a reasonable period of time.
To mitigate this drawback, extensions have been added to BPEL in order to provide for the management of asynchronous calls (for the Web services invoked by the BPEL process as well as for the BPEL process itself relative to a client that has invoked it). An asynchronous implementation of this kind can be done by bringing other emerging standards into play, for example especially “WS-Addressing” used in conjunction with SOAP (Service Oriented Architecture Protocol). The principle of asynchronous calling using “WS-Addressing” is based on the implementing, within the calling party and the called party, of a client and a server. For example:                Let “A” and “B” be two entities. “A” wishes to implement an asynchronous process proposed by “B”. To this end, “A” comprises a client “WCA”, which will call the process of “B”, and a server of “WSA” which will subsequently receive the result coming from “B”, when the service has been performed. This client “WCA” and this server “WSA” must share certain items of data enabling the connection of the call and the return of the response for “A”;        the client “WCA” of the entity “A” calls the asynchronous server “WSB” of the entity “B” (process) in sending it an “endpoint” (URI or Uniform Resource Identifier) of the return “WSB” and a unique instance identifier;        once the BPEL processor “B” has performed the required actions, it sends back the response to the entity “A” in calling the server “WSA” of “A” (the endpoint previously passed by “A”) by means of its client “WCB” of the entity “B” in specifying the unique instance identifier (previously passed by “A”).        A “URI” is a string of characters identifying a, physical or abstract Web resource.        
One drawback of this asynchronous calling technique is related to the cumbersome nature of the mechanisms to be implemented. Indeed, in our previous example, “A” has to implement both a client “WCA” and a server “WSA”, and must furthermore implement, both on this client and this server, not only the SOAP protocol but also other standards (especially “WS-Addressing”) which are not necessarily integrated into all the currently used development tools and are therefore lengthy and complex in their implementing. Thus, the benefits of the BPEL, precisely those of creating and implementing business processes in a simple and swift manner, are lost.
Another drawback of this asynchronous calling technique is that it is not compatible with an embodiment in which the client is a Web browser (or a light terminal) interfacing with a Web application. Indeed, while a Web browser can be found in any client station, an applications server is rarely found. This means that the previously described asynchronous call approach cannot be implemented to mitigate the problem of obtaining a timeout from the client side when the client is a Web browser.